Methods and devices for exchanging messages in an always-on network

ABSTRACT

Components of an “always-on” network exchange messages to, among other things, allow an agent to monitor the “presence status” of an associated user. By monitoring the presence status of the user, the agent may act as a proxy for the user when the user becomes inactive.

Co-pending U.S. patent application Ser. Nos. ______, ______, and ______,incorporated by reference in full herein as if set forth in full herein,disclose methods and devices which, among other things, enables users toconduct communication sessions (e.g., on-line games) quickly and withgreatly reduced airlink time/bandwidth than previously thought possible.In general, the co-pending Applications just mentioned disclose“always-on” methods and devices because even when a user of a device isinactive (e.g., her device is powered-off) an “always-on agent” may actas a proxy and continue to act on behalf of the user/user's deviceduring a given communication session.

BACKGROUND OF THE INVENTION

To carry out the features and functions described in the co-pendingApplications mentioned above novel messages may be exchanged. Thepresent invention is directed at the generation and subsequent exchangeof such messages. The following discussion provides some examples of theformat and content of such messages.

SUMMARY OF THE INVENTION

The present invention provides methods and devices that generatemessages that may be exchanged between components of an “always-on”network and the like. For example, the present invention provides formethods that allow user devices and their agents exchange messages. Inone exemplary method, a device may generate one or more messages, whereeach message contains at least one sub-message. The sub-message may: (a)contain information concerning the presence status of the device and itsassociated user; (b) indicate a subscribe/unsubscribe status to one ormore services; (c) comprise an alert notification; (d) comprise asynchronization signal (“sync”); (e) contain game playing information;or (f) represent common messages, to name just some of the many types ofsub-messages provided by the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a block diagram illustrating an “always-on” architectureaccording to one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION. WITH EXAMPLES

Referring now to FIG. 1 there is shown an always-on architecture 1 inaccordance with one embodiment of the present invention. Thisarchitecture 1 may be used by a service provider to deliver one or moreservices in a manner that is faster than previously thought possiblewhile requiring a minimal amount of changes or upgrades to theprovider's network.

While the discussion which follows will focus on on-line gaming, itshould be understood that the architectures provided by the presentinvention may be used for any number of services; that is, they are notlimited to just gaming services, applications or activities.

In addition, it should be understood that a service provider may choseto implement an always-on architecture provided by the present inventionin any number of ways. For example, one architecture (such asarchitecture 1) may be implemented such that it is underneath anotherapplication (e.g., gaming application). That is to say any third partycommunication applications the service provider has available may lay ontop of the always-on architecture.

To provide the always-on features and functions described in theco-pending Applications mentioned above, such as presencemanagement/proxying, real-time launching of services, and game playingthe components shown in FIG. 1 need to exchange messages with oneanother.

The architecture 1 in FIG. 1 comprises an always-on client 2 (“client”),applications client 2 a (e.g., “game client”), always-on proxy agent 3(“agent”), always-on lobby 4 (“lobby”), an applications/gameserver/engine 5 (e.g., “game server”) and one or more other third partyagents 300. Besides hardware implementations, the client 2 andapplications client 2 a may also comprise one or more software orfirmware programs/applications that may be co-located and stored on acomputer readable medium 20 of some sort (e.g., hard-drive, compactdisc, memory, memory and processor) which may be, in turn, embeddedwithin a larger device 200, such as a wired or wireless telephone,personal digital assistant (PDA), computer, gaming device, or a devicewhich combines one or more functions (e.g., email and voice messaging),etc., . Alternatively, the client 2 and applications client 2 a may bestored on more than one medium or stored on separate mediums. Likewise,the agent 3 and lobby 4 may also comprise one or more applications andmay also be stored on some kind of computer readable medium 30, 40,respectively, that are also part of one or more wired or wirelessdevices, such as a server 34 or the like. Though shown as one component34, it should be understood that the agent 3 and lobby 4 may be separateunits and need not be co-located. When stored on one or more mediums, aprogram/application may comprise code that controls the features andfunctions of a component shown in FIG. 1. More details concerning thearchitecture 1 are set forth in the co-pending Applications mentionedabove.

More specifically, in one embodiment of the present invention, thedevice 200 may interact with the agent 3 through an interface 2 b. Manytimes the device 200 will be a hand-held device (or handset for short).To simplify the explanation which follows we may refer to the device 200as simply a handset, it being understood that this is just one exampleof the type of device that may make use of the messages provided by thepresent invention. In addition, though in our discussion we may statethat the device or handset 200 generates, exchanges or forwardsmessages, many times it is the interface 2 b and/or client2/applications client 2 a that is actually involved in generating,forwarding and/or receiving messages.

Like the client 2 and applications client 2 a, the interface 2 b maycomprise hardware, software, firmware or some combination of the three.When embodied in software/firmware, interface 2 b may comprise one ormore programs/applications that may be co-located and stored on acomputer readable medium 20 of some sort which may be, in turn, embeddedwithin handset 200. When stored on one or more mediums, aprogram/application may comprise code that controls the features andfunctions of interface 2 b. In yet an additional embodiment of theinvention, the interface 2 b comprises software that works inconjunction with an air interface of handset 200.

Continuing, within handset 200 the client 2 and interface 2 b maytypically handle all communications, including the exchange of messageswith agent 3. In one alternative embodiment of the invention, theinterface 2 b may be part of the client 2. For the sake of simplicity,we shall assume this is the case for the remainder of this discussion.However, it should be realized that this is an optional feature of thepresent invention. In accordance with an embodiment of the presentinvention, the client 2 may generate messages formatted as binary UserDatagram Protocol (UDP) packets (i.e., “short binary messages”) in orderto minimize airlink delays and to make the implementation of the network1 and its many agents 3,300 scalable. In general, the messages generatedby both the client 2 and agent 3 may be structured as follows:

-   -   MsgLen|Ver|#SubMsgs|SrcID|DstID|SeqNo|Authentication|(SubMsgs)*        where the asterisk indicates one or more submessages.

The message header of such a message may include the following fieldsfrom the structure above. First, the “SrcID” field (e.g., 4 bytes inlength). This field identifies the component that is sending orforwarding a message. In messages sent from the handset 200 to the agent3, this field contains the identification (ID) of the handset. The ID istypically assigned by a provisioning server (not shown in FIG. 1). Itmay be assigned, for example, when the user subscribes to an always onservice. In messages sent from the agent 3 to the handset 200, thisfield may contain the ID of the agent 3 which also may be assigned by aprovisioning server.

The next field that may be part of the header is the “DstID” field. Ittoo may be 4 bytes in length. This field may be used to identify therecipient of a message. The third field that may be part of the headeris a “SeqNo” field. Again, it may be 4 bytes in length. This field maybe used to indicate the sequence number of a given message. The nextfield that may be part of the header is the “Authentication” field. Aswith the other fields it may be 4 bytes in length. This field may beused to hold content/information to authenticate a sender of a message.It may also be used to assure that a message has not been corrupted oraltered by an unauthorized third party (e.g., by sniffing). The lastfield that will be discussed herein which may be part of the header is a“SubMsgs” field. In accordance with an exemplary embodiment of thepresent invention, this field may in fact comprise a sequence of one ormore sub-messages.

The following discussion will highlight some examples of sub-messages sothat the reader may gain an understanding of the present invention. Ingeneral, sub-messages may be classified into four categories: statesync, presence update, game playing, and common sub-messages. It shouldbe noted that the present invention places no restriction on the numberor type of sub-messages that may be contained in a single message.Instead, a particular combination may be purely based on timing,performance or other considerations.

Further, it should be noted that if a particular message contains atleast one sub-message that requires an acknowledgement (“ACK”) message,then one ACK message should be generated by the recipient of themessage. Depending on the type and requirement of each sub-message, anACK message itself may contain one or more sub-messages.

In accordance with one embodiment of the invention, the generalstructure of a sub-message may take the form of:

-   -   SubMsgLen|SubMsgType|SubMsgPayload

The three sub-fields of the sub-message above may be further describedas follows below. It should be noted that where a number of bytes isindicated as a length of a given sub-field this is merely an exemplarylength. Other lengths may be substituted without changing the principlesof the present invention. The sub-fields are:

-   -   “SubMsgLen”: (2 bytes): This sub-field indicates a length of the        sub-message.    -   “SubMsgType”: (1 byte): This sub-field indicates a sub-message        type.    -   “SubMsgPayload”: This sub-field is for message specific data.

We now turn to a more detailed discussion of the state sync, presenceupdate, game playing, and common sub-messages mentioned above.

In accordance with one embodiment of the present invention, a state syncsub-message is used to synchronize the handset 200 and agent 3, forexample. This type of sub-message is usually sent during a “power on” orinitialization time period during which the device 200, and inparticular, the client 2/interface 2 b, may be enabled. Variousinformation that is stored by the device 200 (and/or agent 3 if it isthe agent that is being powered up) may be updated or synchronizedduring this time period. One examples of such information are: gamelist(s), buddy list(s), home screen features, game screen features, andbuddy screen features, to name just a few examples.

As is known by those skilled in the art, the handset 200 and agent 3 maylose synchronization with one another when, for example, changes occurto either one of them. For example, when a user changes the features ofthe device 200 the agent 3 may not automatically detect these changes.Such changes may involve adding/deleting a buddy to/from a buddy list ormay be triggered when a new game is downloaded. To insure the device 200and agent 3 are once again synchronized, the device 200 may generate andforward a message containing a sync state sub-message related to a giventype of information or change. On the agent 3 side, a sync statesub-message may be generated and sent in order to refresh icons or keyson a display, keypad or the like (not shown in FIG. 1) that is part ofthe device 200 with new information collected, generated, analyzed orotherwise formatted by the agent 3.

The present invention provides for the generation of a plurality ofstate sync sub-messages. In accordance with one embodiment of theinvention, at the beginning of a synchronization process, the handset200 may generate and send a “Sync Request” sub-message to the agent 3,along with five checksums, each checksum associated with a differenttype of state information.

In accordance with the present invention, the agent 3 may associate adifferent checksum with: (a) a most recent version of a particular typeof information, and (b) a previous version of the information. Forexample, upon receiving a “Sync Request” sub-message from the handset200, the agent 3 may be operable to compare the received checksum in thesub-message with, for example, two versions of a checksum previouslystored. Thereafter, the agent 3 may be further operable to determinewhich, if any, information is out of sync and which side (handset oragent) has the most recent version of the information.

Once it has received a Sync Request, the agent 3 maybe operable togenerate and send a “Sync Response” sub-message back to handset 200. Ifit happens that the agent 3 has the latest version of a particular typeof information, the latest state/version of this information may bepiggybacked (i.e., included in) as a part of the “Sync Response”sub-message. If, however, the handset 200 has the latest version, thenthe handset 200 may be operable to generate and send a “Sync Update”sub-message to the agent 3 after receiving the “Sync Response”sub-message from the agent 3. Coming full circle, the agent 3 may yet befurther operable to generate and send a “Sync Update Response”sub-message to the device 200 as an acknowledgement of sorts. Thefollowing are examples of the structure of some of the sync statesub-messages just discussed:

-   -   SYNC REQUEST: may comprise the following sub-fields (with        exemplary, recommended lengths noted in parentheses):        -   Message length        -   Message type: SYNC        -   Sync request payload (Each entry is optional)            -   Type of Sync (1 byte): GameList                -   Checksum (2 bytes)            -   Type of Sync (1 byte): BuddyList                -   Checksum            -   Type of Sync (1 byte): HomeScreen                -   Checksum            -   Type of Sync (1 byte): GameScreen                -   Checksum            -   Type of Sync (1 byte): BuddyScreen                -   Checksum

In accordance with an embodiment of the invention, all of the checksumsmay have a length of 2 bytes by default, unless otherwise indicated.

The next type of sync state sub-message is a Sync Response sub-message:

-   -   SYNC RESPONSE: may comprise the following sub-fields (with        exemplary, recommended lengths noted in parentheses):        -   Message length        -   Message type: SYNC-RESPONSE        -   Sequence number of corresponding request        -   sync update payload            -   Type of update (1 byte): GameList                -   Result (1 byte):                -    0: Ok (no sub-message, etc., follows)                -    1: out of sync, handset version is more recent (no                    other sub-message, etc., follows)                -    2: out of sync, agent version is more recent (hence                    an update may follow)                -   Number of games                -   List of games:                -    (gameIndex, name (string: length, bytes), . . . )            -   Type of update (1 byte): BuddyList                -   Result (1 byte):                -    0: Ok (no sub-message, etc., follows)                -    1: out of sync, handset version is more recent (no                    other sub-message, etc.,follows)                -    2: out of sync, agent version is more recent (an                    update may follow)                -   Number of buddies (for gaming only)                -   List of buddies:                -    (buddyIndex, NAI, ScreenName, . . . )            -   Type of update (1 byte): HomeScreen                -   Result: (1 byte)                -    0: Ok (no sub-message, etc., follows)                -    1: out of sync, handset version is more recent (no                    sub-message, etc., follow)                -    2: out of sync, UA version is more recent (hence an                    update may follow)                -    Number of icons on screen (1byte)                -    List of icons:                -    {iconIndex, gameIndex, #buddies, (buddyIndex1,                    buddyIndex 2) . . . ,}            -   Type of update (1 byte): GameScreen                -   Result (1 byte):                -    0: Ok (no sub-message, etc., follows)                -    1: out of sync, handset version is more recent (no                    sub-message, etc., follows)                -    2: out of sync, agent version is more recent (hence                    an update may follow)                -   Number of icons on screen (1 byte)                -   List of icons:                -    {iconIndex, gameIndex, #buddies, (buddyIndex1,                    buddyIndex2 . . . )}            -   Type of update (1 byte): BuddyScreen                -   Result (1byte):                -    0: Ok (no sub-message, etc., follows)                -    1: out of sync, handset version is more recent (no                    sub-message, etc., follows)                -    2: out of sync, agent version is more recent (hence                    an update may follow)                -   Number of icons on screen (1 byte)                -   List of buddy icons or names (each buddy may be                    shown as a row, along with associated games):                -    {rowIndex, buddyIndex, #games, (gameIndex1,                    gameIndex2, . . . ) }

The next type of sync state sub-message is a Sync Update sub-message:

-   -   SYNC UPDATE: may comprise the following sub-fields (with        exemplary, recommended lengths noted in parentheses):    -   Message length    -   Message type: SYNC-UPDATE    -   Sync update payload (same as a Sync Response message)

The fourth type of sync state sub-message is a Sync Update Responsesub-message:

-   -   SYNC UPDATE RESPONSE: may comprise the following sub-fields        (with exemplary, recommended lengths noted in parentheses):    -   Message length    -   Message type: SYNC-UPDATE-ACK    -   Sequence number of corresponding update    -   Sync Update Confirm Payload: may be the same as the payload of a        Sync Request sub-message.

The final, exemplary type of sync state sub-message is an Offlinesub-message. This type of sub-message may be generated and sent by ahandset to an agent to indicate that the handset is going offline.

-   -   OFFLINE: may comprise the following sub-fields (with exemplary,        recommended lengths noted in parentheses):    -   Message length    -   Message type: OFFLINE

The next type of sub-message is a “presence update” sub-message. Thistype of sub-message may, for example, enable the handset 200 tosubscribe and/or unsubscribe to receive the presence status (e.g.active/inactive) of other devices. A more detailed explanation of thepresence status of a device is given in co-pending U.S. patentapplication No. ______, mentioned above.

In accordance with an embodiment of the present invention, the handset200 may receive updated presence status information after firstsubscribing to receive this information by generating and sending a“Subscribe” presence update sub-message to the agent 3. Alternatively,if the handset 200 generates an “Unsubscribe” sub-message it will notreceive presence update information. Conversely, the agent 3 may forwardthe presence status of a buddy to the handset 200 by generating andsending a “Notify”, presence status sub-message.

In a further embodiment of the invention, the handset 200 may alsoprovide its own presence status (e.g., active/inactive) to the agent 3by generating and sending an “Availability Update”, presence updatesub-message to the agent 3. This may be useful when, for example, a userwishes to enter, or exit, an on-line game or a group/lobby associatedwith such a game.

The following are examples of the structure, format and content of thepresence update sub-messages just mentioned. It should be noted for thesake of completeness, that some of these sub-messages may require anacknowledgement message.

-   -   SUBSCRIBE: may comprise the following sub-fields (with        exemplary, recommended lengths noted in parentheses):        -   Message length        -   Message type: SUBSCRIBE        -   AlertType (1 byte): Presence            -   Number of buddies (2bytes)            -   BuddyIndex1, BuddyIndex2,    -   UNSUBSCRIBE: may comprise the following sub-fields (with        exemplary, recommended lengths noted in parentheses):        -   Message length        -   Message type: UNSUBSCRIBE        -   AlertType: Presence            -   Number of buddies            -   BuddyIndex1, BuddyIndex2,    -   NOTIFY: may comprise the following sub-fields (with exemplary,        recommended lengths noted in parentheses):        -   Message length        -   Message type: NOTIFY        -   AlertType: Presence            -   UserID            -   PresenceInfo ( using one or more types of encoding)    -   AVAILABILITY UPDATE: may comprise the following sub-fields (with        exemplary, recommended lengths noted in parentheses):        -   Message length        -   Message Type: AVAILABILITY        -   ProfileID (1 byte): may include, for example, the values:            OME, WORK, INTRANSIT, INGAME, NA

The third type of sub-message is a game playing sub-message. This typeof sub-message may be generated and sent by the device 200 to the agent3 to: (a) play a game with an anonymous player; (b) invite a buddy(s) toplay a game with the user of device 200; or (c) accept an invitation toplay a game with a buddy, to give just a few examples.

The following are examples of the structure, format and content of somespecific game playing sub-messages provided by the present invention.Again, it should be noted for the sake of completeness that some ofthese sub-messages may require an acknowledgement message.

-   -   PlayWithBuddy: This sub-message may be generated and sent by a        handset to an agent to play a specified game with a specified        buddy. It may comprise the following sub-fields (with exemplary,        recommended lengths noted in parentheses):        -   Message length        -   Message type: PLAY-WITH-BUDDY        -   GameIndex (2 bytes)        -   List of buddies to invite            -   Number of buddies (2 bytes)            -   BuddyIndex1, BuddyIndex2,    -   PlayGameWithAnyone: This sub-message may be generated and sent        by a handset to an agent to play a specified game with any        available player. It may comprise the following sub-fields (with        exemplary, recommended lengths noted in parentheses):        -   Message length        -   Message type: PLAY-WITH-ANY        -   GameIndex    -   Game Invite Alert: This sub-message may be generated and sent by        an agent to a handset/user may comprise the following sub-fields        (with exemplary, recommended lengths noted in parentheses):        -   Message length        -   Message type: GAME-INVITE-ALERT        -   UserID of the inviting player        -   GameIndex    -   Game Invite Reply: This sub-message may be generated and sent by        a handset to an agent. It may comprise the following sub-fields        (with exemplary, recommended lengths noted in parentheses):        -   Message length        -   Message type: GAME-INVITE-RESPONSE        -   Sequence number of the corresponding Game Invite Alert        -   Response (1byte): 0: accept; 1: reject    -   Matching Status Report: This sub-message may be generated and        sent by an agent to a handset/user. It may comprise the        following sub-fields (with exemplary, recommended lengths noted        in parentheses):        -   Message length        -   Message type: MATCHING-STATUS        -   Number of currently matched players (1 byte)    -   Game Start: This sub-message may be generated and sent by an        agent to a handset/user. It may comprise the following        sub-fields (with exemplary, recommended lengths noted in        parentheses):        -   Message length        -   Message type: GAME-START        -   Lobby ID (4 bytes)        -   Game server address (4 bytes)        -   Game session ID

The last type of exemplary sub-message discussed herein is so-called acommon sub-message. One common sub-message is an acknowledgement (ACK)sub-message. This type of sub-message may be generated and sent byeither a handset or agent. It is a generic sub-message that may be usedto confirm the receipt of a message or sub-message. The second type ofcommon sub-message is a “Keepalive” sub-message. This is an optionalsub-message that may be generated and sent by a handset to an agent on aperiodic basis, typically during an “idle” time period (e.g., once every5 minutes). This type of sub-message enables an agent to receive andmaintain the presence status of a handset. It may not be necessary forthe handset to generate this type of sub-message if the handset'spresence status information is available from another source. Thefollowing are examples of the structure, format and content ofacknowledgement and Keepalive sub-messages provided by the presentinvention.

-   -   ACK: may comprise the following sub-fields (with exemplary,        recommended lengths noted in parentheses):        -   Message length        -   Message type: ACK        -   Sequence number of corresponding message being acknowledged    -   Keepalive: may comprise the following sub-fields (with        exemplary, recommended lengths noted in parentheses):        -   Message length        -   Message type: KEEPALIVE

Up until now, the discussion has focused on those messages that may beexchanged between a handset and an agent. However, interfaces betweenthe client 2 and game client 2 a, between the agent 3 and lobby 4, andbetween the lobby 4 and game server 5 are also provided by the presentinvention.

The above discussion sets forth some examples of methods and devicesprovided by the present invention for enabling the exchange of messagesbetween components of an always-on network. The true scope of thepresent invention, however, is provided by the claims that follow whereit should be noted that the term “device” is meant to include devices,like device 200 for example, and/or their associated users.

1. A method for exchanging messages between a client device and analways on agent comprising: generating one or more messages, eachmessage comprising at least one submessage, wherein the at least onesubmessage comprises a presence status that indicates whether a deviceis active or inactive.
 1. The method as in claim 1 wherein the at leastone submessage comprises either a subscribe or unsubscribe submessage.2. The method as in claim 1 wherein the at least one submessagecomprises an alert notification submessage.
 3. The method as in claim 1further comprising forwarding the one or more messages to the always onagent.
 4. The method as in claim 1 wherein the at least one submessagecomprises a synchronization submessage.
 5. The method as in claim 1wherein the at least one submessage comprises a game playing submessage.6. The method as in claim 1 wherein the at least one submessagecomprises a common submessage.
 7. A device for exchanging messages withan always on agent operable to: generate one or more messages, eachmessage comprising at least one submessage, wherein the at least onesubmessage comprises a presence status that indicates whether a deviceis active or inactive.
 8. The device as in claim 8 wherein the at leastone submessage comprises either a subscribe or unsubscribe submessage.9. The device as in claim 8 wherein the at least one submessagecomprises an alert notification submessage.
 10. The device as in claim 8further operable to forward the one or more messages to the always onagent.
 11. The device as in claim 8 wherein the at least one submessagecomprises a synchronization submessage.
 12. The device as in claim 8wherein the at least one submessage comprises a game playing submessage.13. The device as in claim 8 wherein the at least one submessagecomprises a common submessage.